Codecov Report

Attention: Patch coverage is 33.33333% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 63.90%. Comparing base (c1d9cbe) to head (87b2bb7).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #125      +/-   ##
==========================================
- Coverage   64.11%   63.90%   -0.21%     
==========================================
  Files          17       17              
  Lines        1761     1773      +12     
  Branches      289      291       +2     
==========================================
+ Hits         1129     1133       +4     
- Misses        568      575       +7     
- Partials       64       65       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Why is code being copy and pasted over from transformer lens? Is it not possible to just use transformer_lens.HookedSAETransformer: TransformerLensOrg/TransformerLens#536?

Why is code being copy and pasted over from transformer lens? Is it not possible to just use transformer_lens.HookedSAETransformer: neelnanda-io/TransformerLens#536?

@ArthurConmy This was a tough call for me but I think it's probably the right one. T-lens implements it's own SAE which has a few dissimilarities to ours and which might change / go out of sync. Part of this was that I tried to use the T-lens one with SAE Lens and it needed enough changes that don't make sense as PR's to T-lens that I thought it might be best to duplicate / get them in sync.

However, this thinking is cached from a couple of weeks ago and my conviction is less strong now without more context. Possibly worth trying to enumerate the challenges and make changes to my SAE class of the HookedSAE transformer class such that this isn't necessary.

@jbloomAus there is definitely a problem with too many SAEs classes. I think there probably should be one training SAE (likely the SAE in this codebase) and one inference SAE (used for circuit analysis and feature viz), but currently we have

1. SAE for training in this lib
2. SAE for inference in TransformerLens
3. SAE for inference (feature analysis) in sae_vis
4. This proposal too

Which seems too many (already, the fact I had to use 3) and 2) when doing steering vectors work sucked IMO)

ETA: ping me if I should make this a new issue somewhere.

I don't mind having the discussion here.

My thoughts are:

1. Agree that 3 basically shouldn't exist. I'm refactoring SAE vis heavily for Neuronpedia and planning on removing it's native SAE class and having that version just depend on SAE Lens.
2. I'd be surprised if we could avoid having at least 2 SAE classes,but plausibly we can get there (a training and inference class). I take your point, and concede it's worth a second effort to see if we can avoid the duplication (in particular, of HookedSAE Transformer). I'll look at what refactoring to have a training SAE and an inference SAE in SAE Lens and see how close we can make the latter to the T-lens version / whether we can simply rely on the tlens hookedSAE transformer.

@dtch1997 Thanks for this! We now have hooked SAE transformer. I appreciate you doing this and sorry how it turned out with duplicate work. Will try to find a way to make it up to you.